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Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document proposes four optional cryptographic user interface
   suites ("UI suites") for IPsec, similar to the two suites specified
   in RFC 4308.  The four new suites provide compatibility with the
   United States National Security Agency's Suite B specifications.
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1.  Introduction

   [RFC4308] proposes two optional cryptographic user interface suites
   ("UI suites") for IPsec.  The two suites, VPN-A and VPN-B, represent
   commonly used present-day corporate VPN security choices and
   anticipated future choices, respectively.  This document proposes
   four new UI suites based on implementations of the United States
   National Security Agency's Suite B algorithms (see [SuiteB]).

   As with the VPN suites, the Suite B suites are simply collections of
   values for some options in IPsec.  Use of UI suites does not change
   the IPsec protocols in any way.

2.  Requirements Terminology

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

3.  New UI Suites

   Each of the following UI suites provides choices for ESP (see
   [RFC4303]) and for IKEv1 and IKEv2 (see [RFC2409] and [RFC4306]).
   The four suites are differentiated by the choice of cryptographic
   algorithm strengths and a choice of whether the Encapsulating
   Security Payload (ESP) is to provide both confidentiality and
   integrity or integrity only.  The suite names are based on the
   Advanced Encryption Standard [AES] mode and AES key length specified
   for ESP.

   IPsec implementations that use these UI suites SHOULD use the suite
   names listed here.  IPsec implementations SHOULD NOT use names
   different than those listed here for the suites that are described,
   and MUST NOT use the names listed here for suites that do not match
   these values.  These requirements are necessary for interoperability.

3.1.  Suite "Suite-B-GCM-128"

   This suite provides ESP integrity protection and confidentiality
   using 128-bit AES-GCM (see [RFC4106]).  This suite or the following
   suite should be used when ESP integrity protection and encryption are
   both needed.

   ESP:
     Encryption     AES with 128-bit keys and 16-octet Integrity
                      Check Value (ICV) in GCM mode [RFC4106]
     Integrity      NULL
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   IKEv1:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Hash                         SHA-256 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Group Type                   ECP

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

   IKEv2:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Integrity                    HMAC-SHA-256-128 [RFC4868]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Authentication               ECDSA-256 [RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

3.2.  Suite "Suite-B-GCM-256"

   This suite provides ESP integrity protection and confidentiality
   using 256-bit AES-GCM (see [RFC4106]).  This suite or the preceding
   suite should be used when ESP integrity protection and encryption are
   both needed.

   ESP:
     Encryption     AES with 256-bit keys and 16-octet ICV in GCM mode
                      [RFC4106]
     Integrity      NULL

   IKEv1:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Hash                         SHA-384 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Group Type                   ECP

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-384 [RFC4754].
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   IKEv2:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Integrity                    HMAC-SHA-384-192 [RFC4868]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Authentication               ECDSA-384 [RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

3.3.  Suite "Suite-B-GMAC-128"

   This suite provides ESP integrity protection using 128-bit AES-GMAC
   (see [RFC4543]) but does not provide confidentiality.  This suite or
   the following suite should be used only when there is no need for ESP
   encryption.

   ESP:
     Encryption     NULL
     Integrity      AES with 128-bit keys in GMAC mode [RFC4543]

   IKEv1:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Hash                         SHA-256 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Group Type                   ECP

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-256 [RFC4754].

   IKEv2:
     Encryption                   AES with 128-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-256 [RFC4868]
     Integrity                    HMAC-SHA-256-128 [RFC4868]
     Diffie-Hellman group         256-bit random ECP group [RFC4753]
     Authentication               ECDSA-256 [RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.
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3.4.  Suite "Suite-B-GMAC-256"

   This suite provides ESP integrity protection using 256-bit AES-GMAC
   (see [RFC4543]) but does not provide confidentiality.  This suite or
   the preceding suite should be used only when there is no need for ESP
   encryption.

   ESP:
     Encryption     NULL
     Integrity      AES with 256-bit keys in GMAC mode [RFC4543]

   IKEv1:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Hash                         SHA-384 [FIPS-180-2] [RFC4634]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Group Type                   ECP

   For IKEv1, Phase 1 SHOULD use Main mode.  IKEv1 implementations MUST
   support pre-shared key authentication [RFC2409] for interoperability.
   The authentication method used with IKEv1 MAY be either pre-shared
   key [RFC2409] or ECDSA-384 [RFC4754].

   IKEv2:
     Encryption                   AES with 256-bit keys in CBC mode
                                    [RFC3602]
     Pseudo-random function       HMAC-SHA-384 [RFC4868]
     Integrity                    HMAC-SHA-384-192 [RFC4868]
     Diffie-Hellman group         384-bit random ECP group [RFC4753]
     Authentication               ECDSA-384 [RFC4754]

   Rekeying of Phase 2 (for IKEv1) or the CREATE_CHILD_SA (for IKEv2)
   MUST be supported by both parties in this suite.

4.  Security Considerations

   This document inherits all of the security considerations of the
   IPsec, IKEv1, and IKEv2 documents.  See [CNSSP-15] for guidance on
   the use of AES in these suites for the protection of U.S. Government
   information.

   Some of the security options specified in these suites may be found
   in the future to have properties significantly weaker than those that
   were believed at the time this document was produced.
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5.  IANA Considerations

   IANA has created and will maintain a registry called "Cryptographic
   Suites for IKEv1, IKEv2, and IPsec" (see [IANA-Suites]).  The
   registry consists of a text string and an RFC number that lists the
   associated transforms.  The four new suites in this document have
   been added to this registry after approval by an expert designated by
   the IESG.

   The new values for the registry are:

   Identifier              Defined in
   Suite-B-GCM-128         RFC 4869
   Suite-B-GCM-256         RFC 4869
   Suite-B-GMAC-128        RFC 4869
   Suite-B-GMAC-256        RFC 4869
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